エンタープライズアプリケーションを考える上で、最も長く続いている方法の1つは、外部からのイベントに反応するシステムとして考えることです。これは、80年代後半に構造化設計コミュニティで確立された考え方です。「イベント駆動型アーキテクチャ」という名称で現在も耳にするものです。2000年代半ば、私はこれらの種類のシステムのパターンをいくつか収集し始めましたが、それ以来、それらをより実質的なものに変えることができませんでした。その粗削りな性質にもかかわらず、それらはイベントコラボレーションの本質、用語「イベントソーシング」の導入、世界の仮説的な状態を表すための並列モデルの使用、および合意ディスパッチャを使用してドメインロジックをどのように構成できるかについて、いくつかの有用なアイデアを提供していると私は考えています。

昨年の終わり頃、私はThoughtworksの同僚と共に、「イベント駆動型」アプリケーションの本質について議論するワークショップに参加しました。ここ数年、私たちはイベントを多用する多くのシステムを構築しており、それらはしばしば賞賛され、またしばしば非難されてきました。私たちの北米オフィスはサミットを組織し、世界中からThoughtworksの上級開発者が集まり、アイデアを共有しました。

サミット最大の成果は、人々が「イベント」について話すとき、実際にはかなり異なることを意味していることを認識したことです。そこで、私たちは有用なパターンがどのようなものかを解き明かすために多くの時間を費やしました。このノートは、私たちが特定した主なパターンの簡単な要約です。

LMAXは、新しい小売金融取引プラットフォームです。その結果、多くの取引を低レイテンシで処理する必要があります。このシステムはJVMプラットフォーム上に構築されており、単一スレッドで毎秒600万件の注文を処理できるビジネスロジックプロセッサを中心としています。ビジネスロジックプロセッサは、イベントソーシングを使用して完全にインメモリで実行されます。ビジネスロジックプロセッサは、ディスラプター（ロックを必要とせずに動作するキューのネットワークを実装するコンカレンシーコンポーネント）によって囲まれています。設計プロセスにおいて、チームは、キューを使用する高性能コンカレンシーモデルの最近の傾向は、最新のCPU設計と根本的に矛盾していると結論付けました。

CQRSは、Command Query Responsibility Segregationの略です。これは、グレッグ・ヤングによって最初に説明されたパターンです。その中心にあるのは、情報の更新に使用されるモデルと、情報の読み取りに使用されるモデルを異なるものにすることができるという概念です。状況によっては、この分離は価値がありますが、ほとんどのシステムではCQRSはリスクの高い複雑さを加えることに注意してください。

これは私が何度か遭遇したアプリケーションのスタイルです。アプリケーションは主に、ユーザーに何か物の状態に関するリアルタイム情報を提供するレポートアプリケーションです。ユーザーは見ているものについて多くの制御権を持っているため、アクティブなアプリケーションです。特定の領域を掘り下げたり、一般的に表示を操作したりすることができます。しかし、少なくとも主に読み取り専用のアプリケーションです。

人々がエンタープライズアプリケーションを開始するとき、最初の質問の1つは「データベースとどのように通信しますか」です。最近は、「どのようなデータベースを使用するべきか、リレーショナルデータベースか、これらのNoSQLデータベースのどれか」という少し異なる質問をするかもしれません。しかし、考慮すべきもう1つの質問があります。「そもそもデータベースを使用するべきでしょうか？」